Computer systems can be described as comprising three main components: user mode components, kernel mode components, and hardware. The user mode components enable, for example, user applications. Kernel mode components make up the heart of the operating system (OS), which manages all of the computer resources, such as hardware, memory, programs, task scheduling, storage management and communication handling. These can be referred to as “OS kernel services.” The hardware is a physical device, such as a display, earpiece, or keyboard.
Hand-held devices, such as smart phones and pocket PCs, typically have a single processor, or core. The core is typically the processing component in the CPU that processes instructions, and the OS runs on the core. As performance demand for workload increases, the core processing speed also needs to increase. A current, exemplary speed for a mobile handset or hand-held device with the OS running on the core is 800 MHz. As the speed increases, the power consumption also increases. Since a mobile device typically has a limited power source, such as a battery, the hand-held industry is faced with tradeoffs between services, speed, and power consumption on the core running the OS.
In order to perform its functions, the OS performs processes that are transferred into the OS core's virtual memory from their storage addresses in physical memory. The processes are typically small portions of a larger application. Typical OS cores have a variety of processing methods for implementing the processes once they are within the virtual memory.
One example of an implementation method for a process involves breaking the process into one or more “threads,” or sets of threads, that are associated with one or more “contexts.” A “thread” is an individual part of a program that can execute independently of other parts of the program. The thread runs in a specific process, at a priority, and with a thread quantum. The thread quantum is the minimum period of time in which the thread executes. A thread is usually associated with one or more sets of instructions stored in physical locations. When the core “calls” on these threads to perform a part of the process, the core also associates the threads with a context.
The context comprises those other parts of the computer needed to complete the part of the process of the associated thread, such as data stored in the memory. The context can also mean the CPU registers, L1 cache L2 cache, processor mode, and virtual memory mapped region for the process.
A simplistic example is a process for auto-dialing a hand-held telephone. Upon indicating to the computing device within the telephone that an auto-dial telephone call is desired, such as by pushing a button, the OS core would “call” on the threads needed to auto-dial the telephone, such as a thread for connecting to the line and a thread for entering the telephone number to be called. Associated with those threads would be the context, including, for example, data for the outgoing telephone line to connect to, and data to complete the call, such as the contents of an address book or a particular telephone number.
When the OS executes threads and uses the associated context, it is said to be operating in the “OS context.” When the OS has multiple threads to execute, or multiple processes to execute, the OS may switch between the processes, which requires also switching between contexts. Switching between the threads and contexts of the processes is called “context switching.”
When the OS issues a command to execute a process, the command typically includes information about the context(s) and the thread(s). Typically, there are as many commands as there are threads for a particular context, but the OS can divide the process into portions, called tasks. Then, if the OS is interrupted for any reason, it does not have to repeat the process anew. Rather, the OS can begin with the interrupted task or the next task in the process.
The OS executes the tasks and generates events to represent that the tasks are complete. As the tasks are completed, the OS can aggregate the events until the whole process is complete.
Because of its designation as a “manager,” a typical OS is protected from access or modification by the user mode components and by the hardware. One such protection measure uses different codes for the user and OS modes. The OS runs in kernel mode code, while the user mode has a different code. This differentiation in code allows kernel mode code to have an execution privilege that grants the OS access to system memory and all CPU instructions. It also prevents user mode code from directly accessing the hardware or other components controlled by the OS.
As a consequence of this protection measure, the OS is “compartmentalized,” or segregated from other system components, and requires OS-specific components to perform scheduling and management tasks. Therefore, the OS typically has at least an associated memory manager (OSMMU) processing component and scheduler (OSSCH) processing component to implement OS kernel services.
When performing its scheduling and management tasks, the OS typically operates in “virtual mode.” This mode arises after system boot, that is, initial start-up, as when the computer loads programs from the physical memory into the virtual memory of the OS. The OSMMU translates the physical addresses for stored threads and context into virtual addresses, and moves the addresses into virtual memory of the OS. The OS can then “call” to or operate on the virtual addresses without affecting the physical addresses.
During the loading process, the OSMMU creates memory maps to correlate the physical memory and the virtual memory. The memory maps include the virtual and physical addresses for the threads and the addresses for the data that makes up the contexts of the process so that, when the OS issues a virtual command to execute a process, the physical addresses of the threads and contexts can be found.
Since only the addresses are stored in the virtual memory before a command is issued, the OSMMU must translate from the virtual mode to the physical mode so that the physical addresses for the process threads and context can be accessed. The OS can then access the threads and context and, ultimately, the process can be completed.
Prior computer system designers have recognized that a large number of threads must be executed for many processes, with a concomitant storage of contexts. This creates a large burden on the OS. To assist the OS, and an OS scheduler OSSCH can schedule when the processes can be completed. The OSSCH puts threads in a “pipeline,” either as individual threads or as tasks, and the threads are eventually completed. Since the number of threads can be great, and the time to complete an entire process can be long, designers have also utilized multi-core systems, such as systems with multiple processors fabricated on a single semiconductor chip, so that a computer system can have multiple compartmentalized OS cores, each operating at the kernel level.
Multi-core systems typically comprise duplicates of a main OS core, so that each core of the multi-core system has its own dedicated OS-specific components to perform the scheduling and management tasks. Therefore, each OS core of a prior art multi-core system typically has at least its own associated memory manager unit and scheduler to implement the OS kernel services.
This system-wide redundancy leads to several inefficiencies, including duplication of hardware components for the OS cores; non-communication between cores such that a first core does not know what a second core is doing, thus creating redundancy and interference; non-sharing of tasks, such that the cores operate in isolation and do not share parts of the process to be completed; and use of duplicate, high-power cores.
FIG. 1 shows an example of a traditional multi-core operating system 100 in kernel space, with user and hardware modes (details not shown). A main OS core 110 provides kernel services KS1 and comprises a memory manager unit OSMMU 1 and scheduler OSSCH 1. Other cores, 111 and 112, are provided, each with its respective memory managers, OSMMU 2 and OSMMU 3, and schedulers, OSSCH 2 and OSSCH 3. Each core 111 and 112 provides respective OS kernel services KS2 and KS3. Because security features limit access to the cores, the cores of the traditional multi-core OS 100 do not have access to each other's memory maps or to the processes stored in their virtual memory (not shown). Therefore, each core must assemble its own virtual memory, with addresses and maps, through its respective OSMMU.
In some traditional implementations, the memory map of the main OS core 110 is included in OSMMUs of the other cores. This presents a significant outlay and redundancy for memory manager unit capabilities. In addition, each core must assemble its own pipeline, P1, P2, and P3, of tasks through its respective scheduler, with each scheduler unaware of the pipeline of tasks of the other cores. This also presents significant outlay and redundancy, since the cores could execute the same tasks at the same time. Interference can result when the cores vie for the same thread or context addresses at the same time.